The Java 2 Platform, Enterprise Edition (J2EE) specification, developed by Sun Microsystems, Inc., in collaboration with leaders from throughout the enterprise software arena, defines one of the current standards for developing multi-tier enterprise applications. J2EE provides a component-based approach to the design, development, assembly, and deployment of enterprise applications, which both reduces the cost and enables fasten design and implementation. The J2EE platform gives the developer a multi-tiered distributed application model, the ability to reuse components, a unified security model, and flexible transaction control. Not only can they deliver innovative customer solutions to market faster than ever, but the resultant platform-independent J2EE component-based solutions are not tied to the products and application program interfaces (APIs) of any one vendor.
The J2EE specification defines the following kinds of components: application client components; Enterprise JavaBeans (EJB); servlets and Java Server Pages (JSP) (also called Web components); and applets. A multi-tiered distributed application model implies that the application logic is divided into components according to function, and different application components may make up a J2EE application on the same or different servers. Where an application component is actually installed depends on which tier in the multi-tiered J2EE environment the application component belongs. These tiers are depicted in FIG. 1. As shown therein an application server tier 104 is used to develop EJB containers and/or presentation containers such as servlets, JSP, and html pages 114. These in turn are used as an interface between a client tier 102, where the clients 108 and client applications are deployed, and a backend tier 106, used for hosting enterprise or legacy applications such Enterprise Resource Planning (ERP) systems.
Client tier—These can be browsers, Java-based programs, or other Web-enabled programming environments running within the client tier, both inside and outside of corporate firewalls.
Application Server tier—Normally this tier hosts a combination of presentation logic and business logic to support client requests. Presentation logic is supported via JSP pages and servlets that display HTML pages, while business logic is supported via Remote Method Invocation (RMI) objects and EJBs 112. EJBs rely upon the container environment for transactions, lifecycle and state management, resource pooling, security, etc., which together make up the run time environment in which the beans are executed.
Back-end tier—This is generally a combination of existing applications and data stores. It is also referred to as the Enterprise Information Systems (EIS) tier, since it may include such systems as Enterprise Resource Planning (ERP), mainframe transaction processing, database systems, and other legacy information systems.
Since the components of a J2EE application run separately, and often on different devices, there needs to be a way for client and application server tier code to look up and reference other code and resources. Client and application code can, for example, use the Java Naming and Directory Interface (JNDI) 116 to look up user-defined objects such as enterprise beans, and environment entries such as the location of the Java Database Connector (JDBC) DataSource objects, which in turn are used for looking up resources in backend tier, and message connections.
Application behavior such as security and transaction management can be configured at deployment time on Web and enterprise bean components. This deployment time feature decouples application logic from the configuration settings that might vary with the assembly. The J2EE security model lets a developer configure a Web or enterprise bean component so that system resources are accessed only by authorized users. For example, a Web component can be configured to prompt for a user name and password. An Enterprise Bean component can be configured so that only persons in specific groups can invoke certain kinds of its methods. Alternatively, a servlet component might be configured to have some of its methods accessible to everyone, and a few methods accessible to only certain privileged persons in an organization. The same servlet component can be configured for another environment to have all methods available to everyone, or all methods available to only a select few.
Some application servers, such as the WebLogic Server product from BEA Systems, Inc., San Jose, Calif., use an Access Control List (ACL) mechanism that allows for fine-grained control of the usage of components running on the server. Using an ACL, a developer can define at the Java Method level what can, or cannot, be executed by which user or group of users. This ACL mechanism covers anything that runs on the application server except for EJBs, which have their own access control mechanism defined in the EJB specification. Security realms allow the administrator to import information from existing authorization or authentication systems into the ACL.
Java Servlets
A servlet is a program that extends the functionality of a Web server. A servlet receives a request from a client, dynamically generates the response (possibly querying databases to fulfill the request), and then sends the response containing an HTML or XML document to the client. Servlets are similar to CGI but are typically easier to write, since servlets use Java classes and streams. They execute faster because servlets are compiled to Java byte code and at run time the servlet instance is kept in memory, each client request spawning a new thread. Servlets make it easy to generate data to an HTTP response stream in a dynamic fashion. Each client request is performed as a new connection, so flow control does not come naturally between requests. To allow for this session management maintains the state of specific clients between requests. In some application servers, servlets make use of the HTTP session object to save their state between method requests. This object can be replicated in a clustered environment for failover purposes.
Java Server Pages
JSP pages are a text-based, presentation-centric way to develop servlets. JSP pages offer all the benefits of servlets, and when combined with a JavaBeans class, provide an easy way to keep content and display logic separate. Both JSP pages and servlets are more desirable than Common Gateway Interface (CGI), because they are platform-independent, and use less overhead. JSP pages can be used with JavaBeans classes to define Web templates for building a Web site made up of pages with a similar look and feel. The JavaBeans class performs the data rendering, so the templates have no Java code. This means they can be maintained by an HTML editor. Simple Web-based application using a JSP page can be used to bind content to application logic using custom tags or scriptlets instead of a JavaBeans class. Custom tags are bundled into tag libraries that are imported into a JSP page. Scriptlets are small Java code segments embedded directly in the JSP page.
Database Access Services (JDBC)
JDBC acts as a bridge to relational databases, and is modeled on the ODBC (Open Database Connectivity) specification. It decouples the database from the program code through the use of drivers. Some implementations of JDBC provide support for advanced data types, and also support the functionality of scrollable result sets and batch updates.
Java Messaging Services (JMS)
JMS is the J2EE mechanism used to support the exchange of messages between Java programs. This is how Java supports asynchronous communication, wherein the sender and receiver don't need to be aware of each other and thus can operate independently. JMS currently supports two messaging models:
Point to point—which is based on message queues. In this model message producer sends a message to a queue. A message consumer can attach itself to a queue to listen for messages. When a message arrives on the queue, the consumer takes it off the queue and responds to it. Messages can be sent to just one queue and will be used by just one consumer. Consumers have the option to filter messages to specify the exact message types they want.
Publish and subscribe—which allows producers to send messages to a topic and for all the registered consumers for that topic to retrieve those messages. In this case, many consumers can receive the same message.
Java IDL and Multi-Threaded Servers
In the CORBA world, attempts have been made to allow CORBA objects to use an Interface Definition Language (IDL) to specify a contract, i.e., how they are going to interact with other objects. With Java IDL, contracts may be defined between the Java world and the CORBA world. Starting with Sun's Java Development Kit (JDK) Version 1.2, an Object Request Broker (ORB) allows Java applications to invoke remote CORBA objects via the Internet InterORB (IIOP) protocol. In a multi-threaded CORBA server, event queues provide a method for implementing threading policies on that CORBA server. In practice the event queues support the desired threading policy for CORBA requests, and integrate the processing of non-CORBA events within the threading policy. A multi-threaded CORBA server, such as the Orbix server from Iona Software, can for example implement policies which determine how many threads are created, when those threads are created, and which requests are handled by which threads. Implementing a particular policy typically involves creating a number of queues and worker threads and programming a logic to determine which queue to use for each incoming event.
Multi-threaded CORBA servers can thus process several CORBA requests concurrently. One primary advantage of this is to increase overall throughput. Threading policies can be customized for different needs, depending on how the work of handling requests should be shared between them. These options include the following:
One thread per operation: In this scenario a new thread is created to handle each incoming request. This option provides maximum concurrency, but sometimes creates too many threads if the server receives a large number of concurrent requests at peak load.
Use of a thread pool: In this scenario requests are queued and handled by the first available thread in a pool of threads. The maximum number of threads, and hence the server load, is restricted by limiting the size of the pool.
One thread per object: Following this option one or more request queues are maintained for each object. This option provides full concurrency between objects but serializes access to each individual object.
One thread per client: A request queue is maintained for each client. This option ensures equal treatment of clients, by controlling the number of thread resources allocated to each.
Threading in J2EE Servers
One problem with current threading policies as used in J2EE-based transaction and application servers is the concept or prioritization of requests. Although threading policies can be designed for maximum throughput in terms of request management these are few options in terms of request prioritization. Many current server products use a pool of threads for reading requests from clients from the network. Once a complete request is read into the queue it must be dispatched for execution in the server. But there is little to allow a developer to prioritize the complete requests prior to dispatch.
Prioritization of requests is a commonly desired feature, but is difficult to implement because of concerns about the complexity it adds to the underlying server code and because of new problems, such as priority inversion, which it can create. The addition of multiple queues would provide the software administrator or developer with a priority mechanism that manages these concerns better than a true priority scheme would.
Throttling of requests is another feature commonly requested by application server customers. This is commonly requested where part of the workload requires a large amount of memory, CPU time, or other resource. The system can not process many of these requests simultaneously.
Many application servers provide dispatch options that allow a request to execute in the same thread that read the request or to enqueue it on a queue which feeds a pool of worker threads. Using this configuration one can control various quality of service parameters of the requests. For instance requests may be expedited by executing them directly in the thread which read them thus skipping the queue. Alternately some requests may be throttled by assigning them to a queue which is tended by only a limited number of threads.